Modern requirements for a computer system may require that a computer be utilized to run several operating environments, or operating systems, at once. In a typical embodiment, a single logically partitioned computer or data processing system can run a plurality of operating systems in a corresponding plurality of logical partitions (LPARs), also referred to as virtual machines (VMs). Each operating system resides in its own VM, with each VM allocated a part of a physical processor, an entire physical processor, or multiple physical processors from the computer. Additionally, a portion of the computer's memory is allocated to each VM. An underlying partition manager, often referred to as a hypervisor or virtual machine monitor (VMM), manages and controls the VMs. The hypervisor is typically a part of the system firmware and manages the allocation of resources to the operating systems and VMs. As such, one logically partitioned computer may run one or more VMs and thus virtualize the operations of the applications, operating systems, and other program code configured to operate in those logical partitions.
In addition to sharing the physical processors and memory in a logically partitioned computer, VMs also typically share other types of physical hardware resources, which are collectively referred to herein as input/output (IO) resources. For example, in order to provide VMs with access to external networks, logically partitioned computers typically include multiple physical network adapters, e.g., network interface cards (NICs), that are shared by the VMs, such that each VM is allocated at least a part of one or more physical network adapters to enable that VM to access various networks, e.g., local area networks, wide area networks, storage networks, the Internet, etc. Many IO resources, including many network adapters, are compliant with various Peripheral Component Interconnect (PCI) standards. PCI-compliant IO resources typically implement one or more PCI functions, e.g., to support different protocols such as Ethernet, Fibre Channel over Ethernet (FCoE), etc. An IO resource that is shared by multiple VMs may be considered to be a virtualized IO resource within the context of the present disclosure.
In many conventional logically partitioned computers, IO resources are virtualized within the hypervisor, so that conventional device drivers, appropriate for use in both logically partitioned and non-partitioned computers, may be used. Virtualization of an IO resource in a hypervisor typically requires that the hypervisor trap device accesses by the device drivers in the VMs and effectively route the operations to the appropriate physical IO resources. Thus, where multiple VMs share a common physical IO resource, the hypervisor itself handles the multiplexing of operations performed by the physical IO resource on behalf of each VM. Allocating such higher-level functionality to a hypervisor, however, has been found to introduce excessive complexity and processing overhead to the hypervisor. It is desirable in many implementations for a hypervisor to be as small, compact, fast and secure as possible so that the processing overhead of the hypervisor is minimized. As such, other technologies have been introduced in an attempt to off-load the responsibility of virtualizing IO resources from the hypervisor.
For example, in some designs, a dedicated VM, referred to as a virtual input/output server (VIOS), may be used to manage the virtualization of IO resources. While the use of a VIOS offloads higher-level functions from the hypervisor and reduces the overall complexity of the hypervisor, it has been found that using VMs to provide such services to other VMs requires relatively high overhead to instantiate and run the VM, and thus, a full operating system, in order to provide such services.
More recently, some designs have relied upon adjunct partitions (APs), which have also been referred to as partition adjuncts, to assist with the virtualization of IO resources. An AP is a type of partition that is more limited than a full, logical partition or virtual machine. An AP typically runs in a flat, static effective address space and problem state, which permits the hypervisor to apply a range of hypervisor and processor optimizations that result in a substantial decrease in system overhead associated with a context switch of the state machine from an VM to state data of an AP, that is, compared to a context switch of the state machine between two VMs. In other respects, an AP is similar to a full VM. For example, an AP typically can be assigned resources, either physical or virtual, similar to a full VM. Further, an AP can be an end-point of a virtual input output (VIO) communications mechanism, similar to a full VM, such as VIOS.
In addition, some designs have incorporated the concept of self-virtualization of IO resources, where at least a portion of the virtualization of a physical IO resource is handled within the resource itself. The PCI single root input/output virtualization (SRIOV) specification, for example, enables a physical IO resource such as a NIC to incorporate replicated on-board functionality such as memory spaces, work queues, interrupts, and command processing so that a single function such as a single Ethernet connection can be presented to a logically partitioned computer as multiple and separate physical functions. The SRIOV specification introduces the concepts of physical functions (PFs) and virtual functions (VFs), with the former representing full PCI functions and having the ability to instantiate, configure and manage virtual functions, and the latter representing lightweight PCI functions with reduced configuration resources and usable by VMs to access a self-virtualizing device.
It has been found that the use of APs in conjunction with self-virtualizing IO resources provides a flexible, efficient framework with which to virtualize IO resources in a logically partitioned computer, and does so without requiring a separate full VM to provide the virtualization, and without requiring such functionality to be embedded within client VMs or in the hypervisor.
In some designs, virtual functions are allocated fixed bandwidth resources from a physical function of a self-virtualizing IO resource based on user provided capacity or QoS (Quality of Service) settings, with the resources allocated to a virtual function fixed and dedicated to that virtual function throughout the virtual function's lifetime. In practice, however, the allocation of resources to virtual functions may not be optimal as users may not be aware of application characteristics such as bandwidth requirements, and as an allocation that may be optimal at one point in time may not be optimal at another point in time due to changing workloads. As a result, over a period of time it can be observed that some virtual functions may end up being over-utilized (e.g., due to insufficient IO bandwidth and/or adapter resources) while some virtual functions may end up being under-utilized. Also, in other scenarios a self-virtualizing IO resource may be left with some amount of unused and/or unallocated IO resources of which a user may not be aware.
Therefore, a need continues to exist in the art for a manner of optimizing bandwidth allocation among virtual functions in a logically-partitioned computer.